The invention is directed to the field of computer methods to produce application oriented languages.
An application-oriented language (AOL)xe2x80x94what Bentley (1089) calls a xe2x80x9clittle languagexe2x80x9dxe2x80x94is a good way to solve many a problem. An AOL xe2x80x9cknowsxe2x80x9d the nitty gritty and steps needed to solve problems in an application domain, and applies its knowledge automatically as a document written in the language is processed. An AOL frees us to deal with a problem at a higher level of abstraction, and relieves us to the mindless drudgery that is often the cause of errors.
Unfortunately, it takes a lot of expertise and effort to make an AOL. Although tools such as lex (Lesk and Schmidt, 1990), yacc (Johnson and Sethi, 1990), and MetaTool (Cleveland and Kintala, 1988) help, they are no panacea and no substitute for expertise in the art and science of designing and implementiing programming languages. This puts AOLs out of the reach of most domain experts who have the need for them but lack the skills to make their own. If domain experts could make little languages easily, more of their potential to enhance productivity would be realized.
To save on the effort of making an AOL, certain features are often left out; the result is a compromised and less effective AOL. For example, a typical AOL doesn""t have a debugger, can""t be easily extended or customized by its users, lacks scoped variables and data structures, and lacks parameterized functions. The cost of putting these features into an AOL is usually prohibitive given the limited use of each individual language. The hidden cost is that, as users, we must suffer an inadequate AOL over the long haul.
Like many good things in life, too many AOLs may be bad. As they proliferate and our use is spread thinner and thinner over more and more AOLs, we find it harder and harder to achieve mastery of any one, and thend to forget those we use rarely. Their proliferation also creates appliction xe2x80x9cislandsxe2x80x9d that can""t talk to each other. The AOLs that fafcilitate problem solving in their respective domains become barriers for solving large problem spanning multiple domains and requiring communication and coordination among partial solutions written iin different languages. Although people can be multilingual, AOL compilers and interpreters are decidedly monolingual. So we end up with many AOLs that can""t work together.
We propose here a way to reap the benefits of AOLs without incurring many of their costs. The proposal is that AOLs be realized as jargons. Jargons are a family of AOLs that share many features in common, and are distinguished only by the expressions they contain, just like jargons of a natural language like English. The syntax, execution semantics, and other features that jargons share make them easy to learn and remember, and also make it possible to combine different jargons into a new, hybrid jargon capable of solving bigger problems.
We also present the infocentric paradigm and its realization by the Info Wiz system as an easy way to make a jargon. The infocentric paradigm enables someone with no expertise in programming language design and implementation to prototype a jargon in a day and finish it in a week. The infocentric paradigm represents a sea change in how we go about representing and processing information. The change comes about because InfoWiz makes it so easy to solve a problem indirectly by first making a jaragon, and then using the jargon to represent the solution. This approach is called the infocentric paradigm, because it is centered on information modeling as the key to problem solving, in contrast to the conventional algocentric paradigm that is centered on modeling algorithms or procedures.
The infocentric paradigm makes information reuse practical. Iniformation reuse is realized when an AOL document (i.e., xe2x80x9cprogramxe2x80x9d) is kept fixed, but the semantics of the expressions of the jargon are changed on each processing of the document in order to generate different products. This aspect of the infocentric paradigm shows that an Info Wiz document is really a program, but not of the familiar kind. Unlike conventional programs whose free parameters are vairables that take on different data values, the free parameters of an Info Wiz document are expressions that take on different semantics with each distinct reuse.
The original inspiration for Info Wiz was Sharon Murrel""s monk text formatting system (Murrel and Kowalski, 1984). Monk introduced the important idea of using a high-level programming language for writing actions that was different from the base language.
following is a bibliography of prior aork in the field of the invenion:
Anonymous, MetaTool Specification-Driven-Tool Builder. North Andover, Mass.: ATandT Bell Laboratories, 1990.
Bentley, J. L. Little Languages for Pictures in Awk. ATandT Technical journal, July-August 1989,,p..
Cleveland, J. C. and Kintala, C. Tools for Building Application Generators. ATandT Technical Journal, July-August 1988,,p..
Devanbu, P. GENOAxe2x80x94A Customizable, Language- and Front-End Independent Code Analyzer. ATandTBell Laboratories Memorandum 11262-910816-22TM, Aug. 16, 1991.
Emerson, S. L. and Paulsell, K. Troff Typsetting for Unix System. Englewood Cliffs: Prentice Hall, 1987.
Goldfarb, C. F. The SGML Handbook. Oxford, England: Clarendon Press, 1990.
Greer, R. and Belanger, D. G. backtalk: A Text Generator, Tree Manipulator and Macro Processor. ATandT Bell Laboratories Memorandum 112687-931115-18-TMS, Nov. 15, 1993.
Johnson, S. C. and Sethi, R. yacc: A Parser Generator. Anonymous (Ed.) Unix Research System Papers. Tenth Edition. Murray Hill, N.J.: ATandT Bell Laboratories, 1990.
Knuth, D. E. The TEXbook. Reading, Mass.: Addison-Wesley, 1984.
Ladd, D. A. and Ramming, J. C. A*:a Language for Implementing Language Processors. ATandT Bell Laboratories Memorandum BL0112650-930924-17-TM, Sep. 24, 1993.
Lesk, M. E. and Schmidt, E. Lexxe2x80x94A Lexical Analyzer Generator. Anonymous (Ed.) Unix Research System Papers, Tenth Edition, Murray Hill, N.J.: ATandT Bell Laboratories 1990.
Murrel, S. L. and Kowalski, T. J. Overview of Monk 0.2: Typographical Database. ATandT Bell Laboratories Memorandum 11229-841210-12TMS, Dec. 10, 1984.
Nakatani, L. H. and Ruedisueli, L. W. FIT Programming Language. Murray Hill, N.J.: ATandT Bell Laboratories, 1991.
Nakatan.. L. H. and Ruedisueli, L. W. FIT Programming Language Primer. ATandT Bell Laboratories Memorandum 11264-920301-03TMS, Mar. 1, 1992.
Ousterhout, J. K. Tel and the Tk Toolkit. Reading, Mass.: Addison-Wesley, 1994.
Reid, B. K. A High-Level Approach to Computer Document Formatting. In Proceedings of Seventh Annual ACM Conference on Principles of Programming Languages, New York: ACM, 1980.
Jargons are a family of application-oriented languages well-suited for representing a processing complex, hierarchically structures information. A system is presented that automates most of the work of making a jargon, so practically any programmer can make a simple one in a few days. Every jargon has the same syntax, is processed with same ready-made base interpreter, and comes complete with a suite of xe2x80x9cdeluxexe2x80x9d features: debugger, error handler, function definition, associative arrays, varibles, incremental loader, among others. The application-oriented and declarative nature of jargons make them usable by domain experts who are no programmers. The commonalities among all jargons, especially their syntax, make them easy to learn and remember, and make it possible to combine different jargons to solve bigger problems. Jargons facilitate information reuse, whereby the same information document is repocessed to generate multiplocity of products.
One aspect of the invention is a method for automatically producing an application-oriented language for processing hierarchically structured information. The method comprises the steps of:
providing a general-purpose information language for writing expressions associated with a domain of application;
providing a general-purpose programming language for writing actions to be executed on said expressions;
providing an interpreter written in said general-purpose programming language for interpreting documents written with said expressions and actions; and
making an application oriented language that is a member of a family of programming languages that share a common syntax, but differs in its expressions and actions, depending on the domain of application.